A command that exited nonzero was not remembered. If its declared outputs existed
when the next build started, that build reported "Nothing to do (up to date)" and
exited 0, so the failure disappeared:

  build 2 (-k):  Build completed: 0 commands (1 failed)   exit 1
  build 3 (-k):  Nothing to do (up to date).              exit 0

The bisect on the issue localises it to 6ae36d1, which made the index write
unconditional and justified it in the commit message:

  Failed outputs don't exist on disk, so stat fails and they're detected as changed.

That holds only when the failed command produced nothing. `cp %f %o && false`
writes its output and then fails, so the stat succeeds, the hash matches what the
index just recorded, and there is nothing left to notice. Before that commit the
guard was `stats.failed_jobs == 0 && !opts.dry_run` -- exit status was honoured
bluntly, by not writing the index at all, and that commit removed the guard while
arguing about a different category.

So exit status becomes what it should have been: a recorded field. CommandEntry
carries `failed`, set from the scheduler's job results, and a command whose
previous entry is marked failed re-runs regardless of its signature. Restoring the
old guard was the alternative and is worse -- it also discards the successful
commands' state, which is the thing 6ae36d1 legitimately fixed.

Routing matters here and is not interchangeable. The re-run is pushed through
`changed_outputs`, not `forced_cmds`: forced_cmds are OR'd into the affected set
at cmd_build.cpp:2058 *after* collect_affected_commands has computed its closure
over changed files, so a forced id adds exactly one command and its consumers do
not propagate. A failed command that half-wrote its output must reschedule
whatever read that output.

INDEX_VERSION 19 -> 20: RawCommandEntry carries a flags word, 80 -> 88 bytes.

Two e2e scenarios, both observed failing first. The second is the one that pins the
routing: a producer writes PARTIAL and fails, its consumer copies that to the final
artifact, and after the cause of the failure is removed -- with nothing else
changing -- the producer must re-run and the consumer must pick up the corrected
output. Before this change that assertion read "PARTIAL", with the build reporting
success.

Also verified by hand: the failure survives repeated builds (3 and 4 both exit 1),
and clears on the first successful run, after which the next build is a no-op.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TLob4Ef3qyMd3Dnp9q3XmA

From an adversarial review of this PR. The field said "failed during the run that
wrote this index" when it must say "has not succeeded since it last failed", and
that difference reopened #187 through two doors, both reproduced:

  putup -B . -k             # a/ fails, recorded
  putup -B . -k outb.txt    # target build; a/ does not run
  putup -B . -k             # Nothing to do (up to date).   exit 0

and the same via a scoped build, where merge_out_of_scope_commands copied the old
entry forward without its failed flag. tup remembers in both cases; this forgot.

The flag is now seeded from the previous index at detection, carried through any
build in which the command does not run, and cleared only by a successful run of
that command. merge_out_of_scope_commands carries it too, unconditionally: an
out-of-scope command did not run, so its recorded state cannot have advanced.

The consumer scenario did not pin what the commit message claimed it pinned.
Routing retries through forced_cmds -- the alternative the message argues against
-- left both scenarios passing, because final.txt had never been created and the
consumer was scheduled by missing-output detection whatever the routing did. It now
builds successfully first so the consumer's output exists holding V1, and asserts
it reaches V2. Verified by mutation: that routing change now fails the test.

Two scenarios added for the doors above, and the flags/reserved comments corrected
-- there is no CommandFlags type, and Hash256 is std::array<std::byte, 32> so
nothing needed 8-byte alignment; reserved makes the tail padding explicit.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TLob4Ef3qyMd3Dnp9q3XmA